Internet Info 1993

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1993 / Internet Info CD-ROM (Walnut Creek) (1993).iso / inet / internet-drafts / draft-glenn-layer-security-00.txt < prev next >

Wrap

Text File | 1993-09-28 | 58.6 KB | 1,536 lines

Internet Engineering Task Force K. R. Glenn INTERNET-DRAFT NIST September 23,1993 Integrated Network Layer Security Protocol K. Robert Glenn (NIST) glenn@osi.ncsl.nist.gov Status of This Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), it's Areas, and it's Working Groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet-Drafts as reference material or to cite them other than as a "working draft" or "work in progress." To learn the status of any Internet-Draft, please check the 1id-abstract.txt listing contained in the Internet-Drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au. It is intended that this document will be submitted to the IESG for consideration as a standards document. Distribution of this document is unlimited. ABSTRACT The Internet has been moving towards a more standardized and open infrastructure to cope with its growing requirements. One requirement of particular interest and importance is that of network security. With the possible addition of CLNP [ISO8473] as a connectionless network protocol for the Internet the most useful solution is an integrated network security protocol that will provide security services and mechanisms for both IP and CLNP. The protocol defined by this Internet Draft is used to provide security services in support of an instance of communication between network layer entities for either IP or CLNP. An attempt is made to keep the functionality as close as possible to [ISO11577]. As a result this specification contains all of the technical complexities and problems of [ISO11577]. Editorial comments are included to address certain technical issues, such as headers ending on word boundaries, type-length-value encoding problems, etc. that may be outside the scope of [ISO11577]. This specification should be viewed as an initial attempt at identifying a protocol that can provide a set of security services for both IPV4 and CLNP. K. R. Glenn Expires: March 28,1994 [Page 1] INTERNET-DRAFT I-NLSP September 23,1993 1 Introduction The Internet has been moving towards a more standardized and open infrastructure to cope with its growing requirements. One requirement of particular interest and importance is that of network security. With the possible addition of CLNP as a connectionless network protocol for the Internet the obvious solution is an integrated network security protocol that will provide security services and mechanisms for both IP and CLNP. The protocol defined by this Internet Draft is used to provide security services in support of an instance of communication between network layer entities for either IP or CLNP. An attempt is made to keep the functionality as close as possible to [ISO11577]. As a result this specification contains all of the technical complexities and problems of [ISO11577]. Editorial comments are included to address certain technical issues, such as headers ending on word boundaries, type-length-value encoding problems, etc. that may be outside the scope of [ISO11577]. This specification should be viewed as an initial attempt at identifying a protocol that can provide a set of security services for both IPV4 and CLNP. 2 Scope and Field of Application This Internet Draft specifies a protocol to be used by End Systems and Intermediate Systems in order to provide security services in either the Network layer of the OSI protocol suite or the IP layer of the TCP/IP protocol suite. The protocol defined in this Internet Draft is called the Integrated Network Layer Security protocol (I-NLSP). This Internet Draft specifies the following services: 1. data origin authentication 2. access control 3. connectionless confidentiality 4. traffic flow confidentiality 5. connectionless integrity Although the degree of protection afforded by some security services depends on the use of some specific cryptographic techniques, correct operation of this protocol is not dependent on the choice of a particular encipherment or decipherment algorithm; that is left as a local matter for the communicating systems. Furthermore, neither the choice nor the implementation of a specific security policy are within the scope of this Internet Draft. The choice of a specific security policy, and hence the degree of protection that will be achieved, is left as a local matter among the systems that are using a single instance of secure communications. K. R. Glenn Expires: March 28,1994 [Page 2] INTERNET-DRAFT I-NLSP September 23,1993 3 I-NLSP Overview One basic mode of operation of the I-NLSP protocol which is for use in providing a secure connectionless network service. The connectionless network service for required by I-NLSP may be either IPV4 or CLNP and is referred to as the Datagram Forwarding Protocol (DFP). The mechanisms and functionality of I-NLSP are identical for IP and CLNP with the exception of the protected PDU format, which is different because of the unique requirements for the IP and CLNP protocols (ie., header format and address sizes). I-NLSP can be implemented in End Systems and in Intermediate Systems. Only those end systems and intermediate systems that require secure communications will be required to alter their existing IP or CLNP implementations. End systems running IP and/or CLNP without I-NLSP will be able to continue communicating with other end systems and intermediate systems running IP and/or CLNP with or without I-NLSP in a non-protected fashion. Intermediate systems with existing implementations of IP and/or CLNP will not require any changes to be able to forward datagrams protected by I-NLSP. I-NLSP is designed so that it can be optimized to meet a range of requirements from environments where the main concern is high security to environments where the main concern is optimized performance. The I-NLSP protocol makes use of the concept of a Security Association (SA) which is independent of the I-NLSP protocol. A set of attributes defining parameters for security (eg algorithm, keys etc) are defined for the SA. This protocol supports the use of a wide range of specific security mechanisms (both standardized and non-standardized). Users and implementors should choose the security mechanisms for use with this protocol appropriate to enforce their security services and level of protection required. The security protection which I-NLSP attempts to provide is derived from a combination of the protection requested by the I-NLSP user and the protection imposed by some security administration. 3.1 Services provided by I-NLSP This protocol provides the aforementioned security services by encapsulating the data and optionally the datagram header in a Secure Data Transfer (SDT) PDU. Protection mechanisms are then applied to the body of the SDT PDU. The entire SDT PDU is then forwarded to a peer entity as the data portion of DFP datagram. On receipt of a SDT PDU, destined for this I-NLSP entity, the I-NLSP protocol parses the SDT PDU, extracts and removes the protection from the data and passes this unprotected data to the DFP for further processing. K. R. Glenn Expires: March 28,1994 [Page 3] INTERNET-DRAFT I-NLSP September 23,1993 3.2 Services assumed by I-NLSP This protocol assumes to operate somewhere within the network layer of either the TCP/IP protocol suite or the OSI protocol suite. Two services are assumed by the I-NLSP. The first service is access to the Security Association information. The second service is the DFP which provides the vehicle for which protected information is forwarded. 3.3 Security Associations In order to protect an instance of connectionless communication a suitable SA must exist. A SA is a negotiated set of parameters that define the security services and levels of protection between two entities. The SA may be established either "out-of-band" means or using an "in-band" SA Protocol (SA-P). SA establishment, as well as a description of a SA-P, is outside the scope of this specification. 3.4 Functional Overview I-NLSP supports the ability to transfer protected or unprotected connectionless datagrams between peer DFP users. I-NLSP determines locally using Quality of Service (QOS), destination address, and other management information (such as Network Management protocols and the Security Association Protocol) whether protection is needed or not. When the DFP receives data to be forwarded (regardless of whether it came from the user of the network layer or the subnetwork), the DFP uses the I-NLSP to determine if communication is permitted with the destination address and if so whether protection is required. If no protection is required, the data will be sent back to the DFP without change. If protection is required, I-NLSP encapsulates the DFP datagram by use of the Encapsulation Function which: takes an unprotected octet string, applies in order the traffic flow confidentiality, integrity and confidentiality protection mechanisms as appropriate to the protection required and returns a protected octet string. Intermediate system functionality requires that the entire DFP datagram, including the header, be encapsulated. In end systems encapsulating the header is optional. The protected octet string becomes an integral part of the I-NLSP's SDT PDU. The SDT PDU then becomes the data part of a DFP datagram that is then forwarded towards the I-NLSP peer entity. On receipt of data from a peer network layer entity, I-NLSP uses the source address and local information to determine if communication is permitted with the destination address and if so whether protection was applied. If protection was not applied, the datagram is processed normally by the DFP. If protection was required, the I-NLSP entity extracts the protected octet string from the SDT PDU. I-NLSP then extracts the encapsulated datagram from the protected octet string using the Decapsulation Function. The Decapsulation Function takes a protected octet string and applies the appropriate mechanisms to remove the applied protection K. R. Glenn Expires: March 28,1994 [Page 4] INTERNET-DRAFT I-NLSP September 23,1993 and returns an unprotected octet string. The decapsulated datagram is then processed normally by the DFP. In the case of intermediate system functionality this could result in the activation of the encapsulation process before the datagram is forwarded. In the case of multiple encapsulations, multiple decapsulations would be required. 3.5 Security Services and Mechanisms This section describes the mapping between the security services provided by I-NLSP and the mechanisms used to support these services. These mechanisms are not the only mechanisms which can be used to provide security within the I-NLSP. Other mechanisms may be standardized in future and it is possible for private mechanisms to be used with I-NLSP. I-NLSP supports the following security services, if selected, with the mechanisms described: 1. Data Origin Authentication - the mechanism used to provide this service is ICVs in conjunction with key management. 2. Access Control - the mechanisms used to provide this service are Security Labels bound to the data and/or the control of keys and/or use of authenticated addresses. 3. Connectionless Confidentiality - the mechanism used to provide this service is encipherment. This protection optionally includes all DFP header service parameters. 4. Traffic Flow Confidentiality - the mechanism used to provide this service is traffic padding and/or hiding the DFP-address. 5. Connectionless Integrity the mechanism used to provide this service is an ICV. This protection optionally includes all I-NLSP service parameters. The essential feature of the mechanisms supported by I-NLSP is an encapsulation/decapsulation function which supports secure data transfer by using the following mechanisms: 1. Padding for traffic flow confidentiality, block integrity algorithms, and block encipherment algorithms. 2. Integrity Check Value. 3. Encipherment/Decipherment. The mechanisms are carried out in the order given above. K. R. Glenn Expires: March 28,1994 [Page 5] INTERNET-DRAFT I-NLSP September 23,1993 4 Security Association Attributes The following SA Attributes control the operation of I-NLSP and the mechanisms used to provide protection. Their description includes mnemonics used to refer to these attributes in this specification. The associated values to these attributes shall be set up on SA establishment. 1. SA Identification: o My_SAID: Integer of range 0 to (256 ** maxlength) - 1 The local identifier of the SA. o Your_SAID: Integer of range 0 to (256 ** maxlength) - 1 The remote identifier of the SA. Note that maxlength is an integer of range 2 to 126. It is a serious error for there to be more than one SA with the same local identifier. Editor's Note: For all practical purposes, maxlength should be set to no more than 5 octets. This would provide 256**5 possible associations. A fixed maxlength would also eliminate the need for the LI field of the SDT PDU. A fixed length of 5 octets would also resolve the problems associated with not aligning the SDT PDU header on a word boundary. (the header would always be 8 octets and thus end on a word boundary). It is recommended that the LI field should remain and always be set to 5, so that the ability to implement the dynamic nature intended by this text remains. 2. Indicator of whether the I-NLSP initiated or responded to the SA establishment: o Initiator: Boolean This attribute indicates how the initiator to responder flag should be set to detect reflected PDUs. 3. DFP Address of peer I-NLSP entity: o Peer_Adr: Octet string of format specified by DFP. 4. DFP Address of entities served through the remote peer: o Adr_Served: Set of octet strings of format specified by DFP. 5. Protection QOS selected for the SA: o QOS_Label: Format defined by an Agreed Set of Security Rules (ASSR). K. R. Glenn Expires: March 28,1994 [Page 6] INTERNET-DRAFT I-NLSP September 23,1993 o DOAuth: Integer of range defined by an ASSR defined Data Origin Authentication level. o CLConf: Integer of range defined by an ASSR defined Connectionless confidentiality level. o CLInt: Integer of range defined by an ASSR defined Connectionless integrity level. o AC: Integer of range defined by an ASSR defined Access Control level. o TF_Conf: Integer of range defined by an ASSR defined Traffic Flow Confidentiality Level. Editor's Note: The QOS should only be used to recommend the levels of security service. The actual levels are negotiated and set by the Security Association. 6. Parameter Protection. o Param_Prot: Boolean Protect the I-NLSP Source address, I-NLSP Destination address, and I-NLSP QOS parameters within the Secure Data Transfer PDU. 7. Label mechanism attributes: o Label_set: Set of {Label_Ref: Integer Label_Auth: Object Identifier Label_Content: Format defined by Label_Auth} 8. Mechanism Flags selected for the SA: o Padd: Boolean Padding within the Protected-Octet-String to support the Traffic Padding mechanism. o ICV: Boolean Integrity within a Protected-Octet-String contents using an integrity check value. o Encipher: Boolean Encipherment of a Protected-Octet-String to provide confidentiality. K. R. Glenn Expires: March 28,1994 [Page 7] INTERNET-DRAFT I-NLSP September 23,1993 9. Padding Mechanism Attributes: o Traff_Padd: Form defined by an ASSR. Traffic Padding requirements. 10. ICV mechanism attributes: o ICV_Alg: Object Identifier The value of this attribute shall be defined by an ASSR. This attribute implies certain attributes of the integrity mechanism such as separate generate and check algorithms, initialization vectors, etc. o ICV_Blk: Integer Basic block size on which the ICV algorithm operates. The value of this attribute shall be defined by an ASSR. o ICV_Len: Integer The value of this attribute shall be defined by an ASSR. The length of the output of the ICV mechanism. It is not necessary that ICV_Len equal ICV_Blk. o Data_ICV_Gen_Key: form defined by ASSR ICV generation key reference for data. o Data_ICV_Check_Key: form defined by ASSR ICV check key reference for data. The initial value of these "key" attributes shall be set up on SA establishment and can be changed during the lifetime of the association. 11. Encipherment Mechanism Attributes: o Enc_Alg: Object identifier allocated under [ISO9979]. The value of this attribute shall be defined by the ASSR. This attribute implies certain attributes of the encipherment mechanism such as the form and length of any synchronization field, separate encipherment and decipherment algorithms, initialization vectors, etc. o Enc_Blk: Integer Block size of encipherment algorithm. The value of this attribute shall be defined by the ASSR. o Data_Enc_Key: form defined by ASSR Encipherment key reference for data. K. R. Glenn Expires: March 28,1994 [Page 8] INTERNET-DRAFT I-NLSP September 23,1993 o Data_Dec_Key: form defined by ASSR Decipherment key reference for data The initial value of these "key" attributes shall be set up on SA establishment and can be changed during the lifetime of the association. 5 Structure and Encoding of SDT PDUs The I-NLSP protocol uses 2 Secure Data Transfer PDU types, one for IP and one for CLNP. All SDT PDUs shall contain an integral number of octets. The octets in a PDU are numbered starting from one (1) and increasing in the order in which they are sent and received. When consecutive octets are used to represent a binary number, the lower octet number has the most significant value. The bits in an octet are numbered from one (1) to eight (8), where bit one (1) is the low-order bit. When the encoding of a PDU is represented using a diagram in this section; Octets are shown with the lowest numbered octet to the left or above; and within an octet, bits are shown with bit eight (8) to the left and bit (1) to the right. The notations below a box show the length of each field in octets; "var" indicates that the field length is variable. The presence or absence of an "optional" field shall be specified by the attributes contained in the Security Association. Note: The optional fields are optional in that a given security association will require the presence of certain fields and the absence of other fields. Once the Security Association is decided, the presence or absence of each field is determined by the SA Attributes. 5.1 Secure Data Transfer PDU The format of a Secure Data Transfer PDU shall be as shown in Figure 1. +-----------------------------------------------+ | Unprotected Header | Protected-Octet-String | +-----------------------------------------------+ Figure 1: Secure Data Transfer PDU Structure K. R. Glenn Expires: March 28,1994 [Page 9] INTERNET-DRAFT I-NLSP September 23,1993 5.1.1 Unprotected Header The format of the Unprotected Header shall be as shown in Figure 2. +---------------------------------------+ | Protocol | Length | PDU | SAID | | ID | Indicator | Type | | +---------------------------------------+ 1 1 1 var Figure 2: Unprotected Header 1. Protocol Id - This field shall contain the I-NLSP protocol identifier, value 01000101. Editor's Note: As long as I-NLSP and NLSP remain functionally aligned, the PIDs can be the same. Once the functionality diverges a new PID needs to be determined. 2. Length Indicator - This field contains the length of the PDU Type field plus the SAID. 3. PDU Type - This field shall contain the PDU type value of 01001000 or 01001010 to indicate a Secure Data Transfer PDU for CLNP or IP respectively. 4. SAID - The SAID field shall contain the Security Association Identifier of the remote entity (that is, the SA attribute Your_SAID). Editor's Note: A fixed SAID length would also eliminate the need for the LI field of the SDT PDU. It is recommended that the LI exist and always be set to 5, so that the possibility of implementing the dynamic nature intended by this text remains. 5.1.2 Protected-Octet-String The Protected-Octet-String field shall contain the output from an Encapsulate Function. The structure of the Protected-Octet-String is dependent on the specific mechanisms used and is shown in Figure 3. The Integrity Mechanism is applied to the Unprotected-Octet-String. The Encipherment Mechanism is applied to the entire Protected-Octet-String. +--------------------------------------------+ | Crypto | Unprotected-Octet | ICV | Enc | | Sync | String | | Pad | +--------------------------------------------+ Figure 3: Protected-Octet-String K. R. Glenn Expires: March 28,1994 [Page 10] INTERNET-DRAFT I-NLSP September 23,1993 1. Crypto Synchronization: This is an optional field which may contain Synchronization data for specific encipherment algorithms. Its presence, form, and length are implied by Enc_Alg. 2. Unprotected-Octet-String: Figure 4 shows the format for the Unprotected-Octet-String. The encoding of the Unprotected-Octet-String shall be a two octet length of the entire Unprotected-Octet-String, followed by one octet, (Data Type) then a series of TLV encoded Content Fields. The structure of the Unprotected-Octet-String is described in more detail in the following section. 3. Integrity Check Value (ICV): This field contains an Integrity Check Value (ICV). The length of this field shall be defined by the ICV Length contained in the Security Association attributes. 4. Encipherment Pad: This field contains padding for the purposes of supporting block encipherment algorithms for confidentiality. The choice of padding value is a local matter. All I-NLSPEs must be able to discard this field. The format of this field shall be defined in section 5.1.3. The Type code of this TLV field shall be as defined in section 5.1.3. If a two octet pad is required the length shall be zero with no value. If a single octet pad is required a single octet PAD field shall be used instead of an Encipherment PAD field. 5.1.3 Content Fields There are two types of Content Fields, Mechanism-Independent (MI-Content) which contain the data to be protected, and Mechanism-Dependent (MD-Content) which contains information required by the security mechanisms. The Content Length and at least one MI-Content Field are required. +--------------------------------------------------------------+ | Content | Data | MI-Content | ... | MD-Content | ... | | Length | Type | Field | | Field | | +--------------------------------------------------------------+ 2 1 var var Figure 4: Unprotected-Octet-String 1. Content Length This field shall contain the length of the PDU contents from the Data Type field up to the end of the last MD-Content Field. K. R. Glenn Expires: March 28,1994 [Page 11] INTERNET-DRAFT I-NLSP September 23,1993 2. Data Type Bit 8 of this fields shall be the "Initiator to Responder" flag. A value of 1 indicates Initiator to Responder. A value of 0 indicates Responder to Initiator. Bits 1-7 of this field are 0000001. Editor's Note: The existence of this field in [ISO11577] was to relay two items of information. The first, located in bit 8, was which peer entity initiated the SA. It is not clear as to what type of threat this is designed to protect against. The second was used to identify between Connectionless and Connection-Oriented types of data. It is recommended that this field could contain information pertaining to the locations and sizes of the Content Fields. This would eliminate most of the TLV problems associated with this protocol. An example would be: Value Meaning ----- ------- x000 0001 connectionless Data with TLV encoding x000 0010 - x000 0111 reserved for Connection Oriented Protocol x000 1000 connectionless Data with fixed positions, variable lengths. x000 1001 connectionless Data with fixed positions and fixed lengths. 3. Content Field Format The Content Field is a general field format for data values to be placed in the SDT PDUs. Both types of Content Fields are Type-Length-Value Encoded as shown in Figure 5. +---------------------------+ | Type | Length | Value | +---------------------------+ 1 1-3 var Figure 5: Content Field K. R. Glenn Expires: March 28,1994 [Page 12] INTERNET-DRAFT I-NLSP September 23,1993 (a) Type - The MI-Content Field Type shall be set to one of the following values: Value MI-Content Field Type --------- --------------------- 1100 0000 Userdata 1100 0010 Source DFP Address 1100 0011 Destination DFP Address 1100 0101 QOS 1100 0110 Label 1100 0111 Label Reference Editor's Note: An additional MI-Content Field Type may be required to represent a DFP datagram with DFP header. The MD-Content Field Type Shall be set to one of the following values: Value MD-Content Field Type --------- --------------------- 1101 0001 Single Octet Pad 1101 0010 Traffic Pad 1101 0011 Integrity Pad 1101 0100 Reserved (See Encipherment Pad) (b) Length - The Content Field Length shall contain the length of the Content Field Value in octets. The Content Field Length shall be one, two or three octets long. i. If one octet long then bit 8 shall be 0 and the remaining 7 bits define a value length up to 127 octets. ii. If two octets long then the first octet shall be encoded as 1000 0001 and the remaining octet defines the fields length up to 255 octets. iii. If three octets long then the first octet shall be encoded as 1000 0010 and the remaining two octets define the field length up to 65,535 octets. Other values of the first octet are reserved for future use. Editor's Note: The processing requirements needed to parse this type of TLV encoding are extreme. It is recommended that the Length field be altered to be fixed in size depending on the type of the Content Field. (c) MI-Content Field Values i. Userdata - This field contains the DFP Data. Editor's Note: Optionally this field can contain the DFP datagram header. K. R. Glenn Expires: March 28,1994 [Page 13] INTERNET-DRAFT I-NLSP September 23,1993 Editor's Note: The fixed Length size, as recommended above, for this field would be 2 Octets (a Length value of 1 to 65,536). ii. Source DFP Address - This field contains a DFP address. Depending on the PDU Type this field is either a Network Layer address encoded in one of the forms described in [ISO8348Ad2] or a fixed length 4 octet IP address. Editor's Note: The fixed Length size for this field, as recommended above, would be 1 Octet. iii. Destination DFP Address - This field contains a DFP address. Depending on the PDU Type this field is either a Network Layer address encoded in one of the forms described in [ISO8348Ad2] or a fixed length 4 octet IP address. Editor's Note: The fixed Length size for this field, as recommended above, would be 1 Octet. iv. I-NLSP Security QOS - This field shall be used to carry the I-NLSP QOS parameter set. This field shall contain a sequence of octets indicating the levels of protection QOS required in terms of security services. The semantics of the levels is defined as part of the security policy. The octets for each of the security services shall appear in the order indicated below. The sequence of octets can be truncated if the truncated octets all relate to the services that have the QOS value 0. A single octet of value 255 shall indicate that protection QOS requirements have been pre-established. Octet Meaning 1 Connectionless Confidentiality 2 Connectionless Integrity 3 Data Origin Authentication 4 Access Control 5 Traffic Flow Confidentiality Editor's Note: The fixed Length size for this field, as recommended above, would be 1 Octet. v. Label - This field shall be used to carry the security label of a PDU. This field is not present if a Label Reference Content field is present. +-----------------------------------------------+ | Authority | Defining | Label | Label | | Length | Authority | Length | Content | +-----------------------------------------------+ Figure 6: Label Value K. R. Glenn Expires: March 28,1994 [Page 14] INTERNET-DRAFT I-NLSP September 23,1993 The structure and interpretation of the Contents of the Label are defined by various Defining Authorities. Editor's Note: The fixed Length size for this field, as recommended above, would be 2 Octets. vi. Label Reference - This field identifies one of the set of security labels defined in the SA attribute Label_Set. This field shall always be encoded so that the value part of the field is two octets. This field shall not be present if a Label Content field is present. Editor's Note: The fixed Length size for this field, as recommended above, would be 1 Octet. (d) MD-Content Field Values i. Single Octet Pad - This field shall be a 1 octet (type without Length or Value) field for general padding (for example, to support a single octet of integrity padding). This octet may be used instead of a TLV encoded Integrity, Encipherment, or Traffic Pad field to provide integrity, encipherment, or traffic padding. All I-NLSPEs shall detect and discard this field. ii. Traffic Pad - This field contains padding for the purposes of traffic flow confidentiality. The choice of padding value is a local matter. All I-NLSPEs shall detect and discard this field. If a two octet pad is required the length shall be zero with no value. If a single octet pad is required a Single Octet Pad shall be used instead of a Traffic Pad. iii. Integrity Pad - This field contains padding for the purposes of supporting block integrity algorithms. The choice of padding value is a local matter. All I-NLSPEs must be able to discard this field. If a two octet pad is required the length shall be zero with no value. If a single octet pad is required a Single Octet Pad shall be used instead of an Integrity Pad. 6 I-NLSP Protocol Functionality This section describes the protocol utility functions for I-NLSP. 6.1 Using QOS to determine Security Policy The following QOS security sub-parameters are modifications to any existing Quality of Service security parameters. Table (a) identifies the placement of these parameters depending on whether data is to be encapsulated or decapsulated. Within the QOS parameter protection may be specified by either explicitly stating the following protection QOS sub-parameters indicating the level of protection for each service K. R. Glenn Expires: March 28,1994 [Page 15] INTERNET-DRAFT I-NLSP September 23,1993 requested or explicitly stating a security label which implies protection requirements. 1. Data Origin Authentication 2. Access Control 3. Connectionless Confidentiality 4. Traffic Flow Confidentiality 5. Connectionless Integrity Table a -- Security Quality of Service Parameters Security Quality of Service Encapsulated Decapsulated --------------------------- ------------ ------------ Data Origin Authentication X X Access Control X X Connectionless Confidentiality X X Traffic Flow Confidentiality X X Connectionless Integrity X X Security Label X X(=) Note 1: In this table X indicates QOS parameter may be present; (=) indicates that Indication parameter must be the same as the Request parameter. Note 2: It is possible for an administratively imposed security policy to be enforced by the I-NLSPE, in which case the policy may dictate a level and type of security protection which is not identical to that requested by the DFP user. However the security label is a sensitivity indication and its value will be that given by the user or his agent and will not be changed by the I-NLSPE. Editor's Note: It is recommended that the Security QOS be used in the Security Association negotiations, but not in the decision for the actual security mechanisms applied to the data. 6.2 Checks At many points in the following descriptions, the I-NLSP entity checks that some condition is satisfied. Unless otherwise specified, whenever such a check fails, the I-NLSP entity shall discard the data currently being processed. Optionally, the entity may also file an audit report. What failures are to be audited is considered to be a local matter. 6.3 Identification of the Security Association An I-NLSPE receiving a request for an instance of communication identifies among the SAs available to it an SA whose attributes satisfy the following conditions: 1. If the I-NLSP Protection QOS is specified then this Protection Set equals the following SA attributes: QOS_Label, DOAuth, AC, CLConf, TF_Conf, and or CLInt. K. R. Glenn Expires: March 28,1994 [Page 16] INTERNET-DRAFT I-NLSP September 23,1993 2. The I-NLSP Destination Address is contained within the set of DFP addresses in Adr_Served. The procedure to be followed if more than one SA satisfies these conditions is a local matter. If no such SA exists and if "in band" SA establishment is supported then the Security Association Protocol (SA-P), option may be selected. An SA may be established "in band" using a SA-P. Otherwise "out-of-band" SA establishment procedures may be followed. If neither of these procedures cannot be completed successfully within a locally defined timeout then error recovery procedures as defined in section 6.2 will be carried out. 6.4 Use of a Security Association Protocol When two I-NLSPEs do not have an SA established, they may establish an SA by notifying a Security Association Protocol (SA-P) or some other method. A SA-P will then optionally perform the necessary steps to establish, modify, or terminate a SA. An SA-P may be based on either symmetric or asymmetric algorithms. The SA-P is a separate protocol, typically at the application layer, used to provide security attribute management. The SA-P is mentioned within this document so that the relationship between the SA-P and I-NLSP is better understood. Editor's Note: It is recommended that the Security QOS be used by the SA-P to help establish or modify a SA. 6.5 Initial Checks An I-NLSP entity (I-NLSPE) receiving a request for an instance of communication shall check that: 1. The I-NLSP Source Address is an DFP address served by this I-NLSPE as determined by local security policy. 2. The I-NLSP security label or protection QOS is within the set of labels or protection QOS that can be processed by this I-NLSPE as determined by local security policy. 3. If unprotected instances of communication are allowed to the I-NLSP Destination Address and the I-NLSP Protection QOS parameter does not indicate any protection requirements then I-NLSP shall allow the DFP to forward the datagram without change. 6.6 Processing a DFP request for Encapsulation Once it has been determined that Encapsulation is required and a SA exists for this instance of communication, a SDT PDU shall be generated. 6.6.1 Generate Secure Data Transfer PDU The following procedures shall be formed when generating a Secure Data Transfer PDU: K. R. Glenn Expires: March 28,1994 [Page 17] INTERNET-DRAFT I-NLSP September 23,1993 1. The Data Type Field bit 8 shall be set to the Initiator value contained in the SA. 2. The Data Type Field bits 1-7 are set to the value defined in 5.1.3. 3. If (Param_Prot is TRUE) then at least one of the following shall be performed depending on local security policy: (a) Place the source DFP address in the Source Address Content Field as defined in 5.1.3. (b) Place the destination DFP address in the Destination Address Content Field as defined in 5.1.3. (c) Place the I-NLSP QOS parameter set in the QOS Parameter Content Field as defined in 5.1.3. 4. Place the DFP Userdata in the User Data Content Field as defined in 5.1.3. The DFP header is also included in this field if either this or the peer I-NLSPE is operating as an IS or optionally otherwise. Editor's Note: Another SDT PDU field may be required to determine whether the DFP header is included. The DFP existing header is necessary for forwarding after running the I-NLSP decapsulate function. Information other than Source address, Destination address and QOS are required for further processing (ie., segmentation and reassembly information). This could easily be implemented using another MI-Content Field Type. Editor's Note: It is unclear that if the DFP header is included in the Userdata Content field that the other fields are necessary. It is equally unclear that if the I-NLSP QOS is only to be used by the SA-P, why should it be transmitted as part of an SDT PDU. 5. If (Label is TRUE) then either: (a) a security label, shall be placed in a Label Content Field and included in the PDU, or (b) a security label reference, shall be placed in a Label Reference Content Field and and included in the PDU. 6. The Encapsulation function shall be called with the following arguments being passed: (a) SAID shall be set to My_SAID. (b) unprotected-octet-string shall be set to the constructed PDU fields. K. R. Glenn Expires: March 28,1994 [Page 18] INTERNET-DRAFT I-NLSP September 23,1993 7. The Encapsulation function shall return either an error or a Protected-Octet-String. Upon successful completion of the Encapsulate function the following processing shall be performed to create an Unprotected Header for the SDT PDU. 8. The Protocol ID field shall be set to the value defined in 5.1.1. 9. The LI field shall be set to the value of 1 + the length of Your_SAID as defined in 5.1.1 and appended to the Protocol ID field. 10. The PDU Type field shall be set to the value defined in 5.1.1 and appended to the LI field. 11. The SAID field as defined in 5.1.1 shall be set to the value in Your_SAID and appended to the PDU Type field. 12. The protected-octet-string shall be appended to the SAID field. 13. The data parameter shall be set to equal the SDT PDU constructed by the above. Upon successful completion of the Encapsulate function the data parameter shall be set to equal the protected-octet string. 6.6.2 Encapsulation Function This section defines an Encapsulation function. This Encapsulation function is based on three functions: Padding, ICV, and Encipherment. The decision to employ a particular function shall be based on attributes of the SA. If traffic padding is selected, a traffic padding field may be added. If a block integrity algorithm is used, an integrity padding field may be added. If integrity checking is selected, an ICV shall be computed over and appended to the above fields. If a block encipherment algorithm shall be used, an encipherment padding field may be added. If encipherment is selected, the above fields are enciphered using the encipherment key for the Security Association. The procedure described above encapsulates user data and other I-NLSP protocol parameters to provide protection for transfer over a network. At the remote end, the recipient of a Secure Data Transfer PDU removes and checks protection by reversing the procedure order. Editor's Note: To simplify this protocol it is recommended that only one pad field be used for all padding functionality. 6.6.2.1 Procedures As encapsulation takes place, a PDU shall be formed by appending or pre-pending fields. These fields may be optional. A partially formed PDU is referred to be low as "existing fields". During decapsulation a PDU shall be decomposed by removing fields. A partially decomposed PDU is referred to below as "remaining data". Note: The description of appending and pre-pending fields is not meant to constrain implementations of I-NLSP but rather to unambiguously specify the protocol. K. R. Glenn Expires: March 28,1994 [Page 19] INTERNET-DRAFT I-NLSP September 23,1993 6.6.2.2 Functionality The SAID shall be used to reference a Security Association. If the Security Association does not exist then the error SA-not-available shall be returned and the value of protected-octet-string shall be undetermined. The unprotected-octet-string shall be placed in an Unprotected-Octet-String Field. The Unprotected Octet String Length field shall be pre-pended and its value shall be made equal to the length of the Unprotected Octet String. If (Padd is TRUE) then an amount and form of padding as determined locally by the ASSR rules referred to in Traffic_Padd shall be placed in a Traffic Padding Content Field and appended to the existing fields. If a single octet of padding is required, then the Single Octet Padding Content Field shall be used. A Content Length shall be pre-pended to the existing fields. The length of all existing fields shall be determined and placed in the Content Length. If (ICV is TRUE) and (ICV_Blk >1) then, if necessary, an Integrity Pad field shall be appended to the existing fields such that the length of the existing fields with the Integrity Pad field (including the protected content field) is an integral multiple of the ICV block size (that is, ICV_Blk). If present, then an amount and form of padding as determined by local security policy shall be placed in the Integrity Pad Content Field. If a single octet of padding is required, then the Single Octet Pad Content Field shall be used. The Content Length value shall be increased by the amount of padding added. If (ICV is TRUE) then an ICV of length ICV_Len shall be calculated over, and appended to, the existing fields. The algorithm used shall be identified by ICV_Alg and the key used shall be the Data_ICV_Gen_Key. If (Encipher is TRUE) then a crypto synchronization Field with a form and length as determined by the Alg_Id shall be generated and pre-pended to the existing fields. If (Encipher is TRUE) then an encipherment pad shall be appended to the existing fields so that the length of the existing fields (that is, Protected Data Length, Unprotected-Octet-String, Integrity Pad, and ICV fields) plus the length of an encipherment pad shall be an integral multiple of the encipherment block size (that is, Enc_Blk). If present, then the amount and form of padding as determined by local security policy shall be placed in an Encipherment Pad Content Field. If a single octet of padding is required, the Single Octet Padding Content Field shall be used. If (Encipher is TRUE) then the existing fields are enciphered. The algorithm used shall be identified by Enc_Alg and the key used shall be either the Data_Enc_Key The constructed PDU shall be returned as the result in protected-octet-string. K. R. Glenn Expires: March 28,1994 [Page 20] INTERNET-DRAFT I-NLSP September 23,1993 6.6.3 Sub-Network Request The SDT PDU shall be encapsulated as a DFP datagram and forwarded by the DFP to the peer I-NLSPE. The DFP datagram Source Address shall be the DFP-address of this I-NLSPE. The content of non-security relevant QOS parameters shall be determined by local policy but may be obtained from the I-NLSP QOS. The DFP datagram Destination Address shall be set to the DFP-address of the peer I-NLSPE. Note: If record route and source route parameters are in I-NLSP QOS parameters and are not passed as QOS parameters, then the specified QOS may not be provided for the part of the route between source and destination I-NLSP entities. 6.7 SDT PDU/DFP Encapsulate Request Relationships Figure 7 shows how the SDT PDU encodings described above are derived and how they relate to each other when processing a DFP Request for encapsulation. 6.8 Processing a DFP request for Decapsulation In addition to the initialize checks performed for any instance of communication the following checks are also performed. 6.8.1 Destination Address Check The I-NLSP shall check that the DFP Destination Address is a DFP-address served by this I-NLSP entity. 6.8.2 Check Received Secure Data Transfer PDU The following procedures shall be formed when parsing a Secure Data Transfer PDU: 1. The I-NLSPE shall identify among the SAs available to it an SA with My_SAID equal to the SAID Field in the received PDU. All further operations refer to this identified SA. If Param_prot is TRUE then the I-NLSPE shall set the actual DFP addresses to the values contained in the SDT PDU. Otherwise the addresses contained in the DFP header will be used. The I-NLSP entity shall check that the DFP Source Address is the address of an DFP User entity reachable via the peer I-NLSP entity. If Param_prot is TRUE, then the actual protection QOS shall be derived from the Protected Octet String of the SDT PDU. Otherwise any protection QOS contained in the DFP datagram header will be used. 2. The Unprotected Header shall be discarded from the PDU. 3. The Decapsulate Function shall be called with the following arguments being passed: K. R. Glenn Expires: March 28,1994 [Page 21] INTERNET-DRAFT I-NLSP September 23,1993 (a) SAID shall be set to My_SAID (b) protected-octet-string shall be set to the remainder of the PDU. 4. The Decapsulate function shall return either an error or an unprotected-octet-string. Upon successful completion of the Decapsulate function the following processing shall be performed. 5. The Data Type Field, bit 8 (Initiator to Responder) flag shall be checked to NOT equal the value of Initiator in the SA. 6. Data Type Field, bits 1-7 shall be checked to be a value defined in 5.1.3. 7. If (Label is TRUE) then the PDU shall be checked to ensure that one and only one Label or Label Reference Content Field is present; else the remaining data shall be checked to ensure that no Label or Label Reference Content Field is present. If present, the value of the label shall be checked to ensure it is contained in the set Label_Set. 8. If (Param_Prot is TRUE) the PDU shall be checked to ensure that at least one of the following fields is present: (a) Destination Address. (b) Source Address. (c) QOS. 9. The PDU shall be checked to ensure that, at most, one Destination Address Content Field is present. If present, the value shall be checked to ensure that it is an DFP address served by this I-NLSPE as determined by local security policy. 10. The PDU shall be checked to ensure that, at most, one Source Address Content Field is present. If present, the value shall be checked to ensure that it is an DFP address contained in Adr_Served. 11. The PDU shall be checked to ensure that, at most, one QOS Parameter Content Field is present. If present, the Protection QOS values within this field shall be checked to ensure they equal the following SA attributes: QOS_Label, DOAuth, AC, CLConf, TF_Conf, and CLInt. 12. If (Param_Prot is FALSE) the PDU shall be checked to ensure that no Destination, Source, or QOS Parameter Content Fields are present. 13. The PDU shall be checked to ensure that, at most, one Data Content Field is present; else the PDU shall be checked to ensure that a Data Content Field is not present. 6.8.3 Decapsulate Function If any of the following checks fail all security relevant status information will be set to the security status information before K. R. Glenn Expires: March 28,1994 [Page 22] INTERNET-DRAFT I-NLSP September 23,1993 reception of this message, except for alarm, auditing, and/or accounting information. The SAID argument shall be used to reference a Security Association. If the Security Association does not exist then the error SA-not-available shall be returned and the value of unprotected-octet-string shall be undetermined. If (Encipher is TRUE) then the following steps are taken: a) The protected-octet-string shall be decrypted. The decipherment algorithm used shall be identified by Enc_Alg and the key used shall be the Data_Dec_Key. b) The Crypto Synchronization field shall be removed by discarding a number of octets, as determined by the Enc_Alg, from the front of the deciphered data. c) The Encipherment Pad or Single Octet Pad Content Field shall be removed by adding the Contents Length and ICV_Len then discarding any octets in the remaining deciphered data which are beyond the calculated length. If (ICV is TRUE) then the following steps are taken: a) The ICV field shall be verified by checking the last ICV_Len octets of the remaining data. The algorithm used shall be identified by ICV_Alg and, if cryptographically based, the key used to calculate the ICV shall be the Data_ICV_Check_Key. b) If the ICV verification fails, then the error data-unit-integrity-failure shall be returned and the value of unprotected-octet-string shall be undetermined. The ICV shall be removed by discarding any octets in the remaining data which are beyond the length contained in Content Length + 2. Content fields that the decapsulate function does not recognize are ignored. The Content Length field shall be removed by discarding the first two octets of the remaining data. Any Traffic Padding, Integrity Padding, or Single Octet Padding Content Fields are removed from the remaining data by removing data beyond the Unprotected Octet String. Note: The Content Fields are located by decoding the contents of the Unprotected Octet String, which is a one-octet Type field followed by a number of TLV fields. The value of the Unprotected-Octet-String shall be returned as the result in unprotected-octet-string. Data from the unprotected-octet-string is extracted and sent to the DFP for further processing. This could result in: Passing the data to the user of the DFP; Forwarding the data toward the protected destination (possibly re-encapsulating the datagram); or being passed back to I-NLSP for additional decapsulation. 6.8.4 SDT PDU/DFP Decapsulate Request Relationships Figure 8 shows how the SDT PDU encodings described above are derived and how they relate to each other when processing a DFP Request for decapsulation. K. R. Glenn Expires: March 28,1994 [Page 23] INTERNET-DRAFT I-NLSP September 23,1993 +-------------------------------------+ | DFP Header | User Data | +-------------------------------------+ | | Generate MI-Content Fields V +---------------------------------------+ | Data | MI-Content | MI-Content | ... | | Type | Field | Field | | +---------------------------------------+ | | Encapsulate Function V +--------------------------------------------------------------------+ | Crypto | Content | Data | MI-Content | .. | MD-Content | .. | | Sync | Length | Type | Field | | Field | | +--------------------------------------------------------------------+ | | Generate SDT PDU V +--------------------------------------------------------------+ | PID | Length | PDU Type | SAID | Protected-Octet-String | +--------------------------------------------------------------+ | | Forward SDT PDU V +-------------------------+ | DFP Header | SDT PDU | +-------------------------+ Figure 7: Encodings and Relationships K. R. Glenn Expires: March 28,1994 [Page 24] INTERNET-DRAFT I-NLSP September 23,1993 +-------------------------+ | DFP Header | SDT PDU | +-------------------------+ | | Discard DFP Header V +--------------------------------------------------------------+ | PID | Length | PDU Type | SAID | Protected-Octet-String | +--------------------------------------------------------------+ | | Decapsulate Function V +--------------------------------------------------------------+ | Content | Data | MI-Content | ... | MD-Content | ... | | Length | Type | Field | | Field | | +--------------------------------------------------------------+ | | Parse Unprotected-Octet-String V +---------------------------------------+ | Data | MI-Content | MI-Content | ... | | Type | Field | Field | | +---------------------------------------+ | | Send User Data to DFP V +------------------------------------------------+ | DFP Header(optional) | User Data | +------------------------------------------------+ Figure 8: Encodings and Relationships K. R. Glenn Expires: March 28,1994 [Page 25] INTERNET-DRAFT I-NLSP September 23,1993 References ---------- [ISO8473] ISO/IEC. Protocol for providing the connectionless-mode network service. International Standard 8473, ISO/IEC JTC 1, Switzerland, 1986. [ISO8348Ad2] ISO/IEC. Information processing systems -- data communications -- network service definition addendum 2: Network layer addressing. International Standard 8348/Addendum 2, ISO/IEC JTC 1, Switzerland, 1988. [ISO9972] ISO/IEC. Information technology - Data Cryptographic Techniques - Registration Procedures for Cryptographic Algorithms. [ISO11577] ISO/IEC. Information technology - telecommunications and information exchange between systems - network layer security protocol. Draft International Standard 11577, ISO/IEC JTC 1, USA, November 1992. K. R. Glenn Expires: March 28,1994 [Page 24]